ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた

こんにちは、高崎＠アノテーションです。

はじめに

過去の拙記事にも何度か登場している自身の LINE ボットの環境ですが、cdk のスタック定義が約 100 行、Lambda のソースが約 370 行と注ぎ足し注ぎ足しでだんだんと大きくなってきました。

一方、業務で使用している環境はドメイン駆動モデルを元に設計・構築を行っているものが多いため、これらの環境やドメイン駆動設計を学んだことを実践すべく、この LINE ボット環境をリファクタリングしてみました。

この記事の対象

筆者と同じく「ドメイン駆動設計を始めたばかりの方」向けと考えております。

今回の内容は筆者個人が参考文献を元に記載した記事で、ドメイン駆動設計の正確性としては程遠い可能性があることを予めご了承ください。

参考文献

• 文献１：ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
• 文献２：現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

対象となる環境について

ベースとなるソース

本記事のベースとなるソースは、下記の記事で作成したソースになります。

構成図

AWS サービスの構成図をざっくりと作ってみました。

ユースケースを考える

機能

今回の一連のシステムは機能だけを見ると下記の通りです。

• メモを保存する機能
• メモの一覧を取得して表示する機能
• メモを削除する機能
• 生成 AI に画像を描いてもらう機能

ユースケース図

機能を元にすると、以下のようなユースケース図が考えられます。

API がそれぞれ用意されていた場合は上記で良いですが、本環境はボット受付の API が一つのみのため、LINE ボット受付のユースケースから各処理が繋がる下記のようなユースケース図としました。

ドメインモデルを考える

ドメインモデルは保存するメモ、および、生成 AI に依頼する生成画像をモデリングすることになります。

それぞれ関連性を持たず独立しているため、クラス図のようになってしまいました。¹

インフラストラクチャについて

各機能で使用するインフラストラクチャは下記の通りです。

• LINE Messaging API
• DynamoDB
• Bedrock
• S3
• Systems Manager（シークレットトークンの保存先）

今回のリファクタリングに向け、DI コンテナも実践しようかと思いますので、各機能とインフラストラクチャ層を整理しました。

• コマンド実行
  • LINE Messaging API
  • Systems Manager
• メモを保存する
  • DynamoDB
• メモの一覧を取得する
  • DynamoDB
• メモを削除する
  • DynamoDB
• 画像生成
  • Bedrock
  • S3
• オウム返し→インフラストラクチャ層無し

おわりに

今回はリファクタリングを行う環境に対して、ドメイン駆動設計の実践をしてみました。

これが正解というわけではないですが、一例として皆さまのベストプラクティスに向けた一助になれば幸いです。

次回は実装を行いたいと思います。

※2023/12/31 追記
実装編を下記に記載しました。以降順次リンクを張っていきます。

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。
「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。
現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。
少しでもご興味あれば、アノテーション株式会社WEBサイト をご覧ください。